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17. (New) The computer program product of claim 1 6, wherein the connection- 
specific driver layer transmits the connection-specific device control commands via a first 
L2CAP channel and transmits the connection-specific data via a second L2CAP channel. 



18. (New) The computer program product of claim 14, wherein the connection- 
specific driver layer translates the device control commands and data encapsulated in the 
connection-independent format into connection-specific device control commands and data with 
reference to a service discovery protocol record. 



19. (New) The computer program product of claim 14, wherein the connection- 
specific driver layer transmits the connection-specific device control commands and data by 
segmenting the connection-specific device control commands and data into packets smaller than 
a maximum transmission unit of a wireless protocol used by the wireless device. 



REMARKS: 

Text from the publications incorporated by reference has been inserted directly into the 
specification to provide greater clarity and context for the disclosure in the specification. 
Specifically, text was copied fi-om the co-pending application. Serial No. 09/302,735, entitled 
"Method and System for Abstracting Network Device Drivers" by Hyder et al., filed on April 30, 
1999, and assigned to the assignee of the present application. The text was inserted as additional 
paragraphs following the paragraph in which the co-pending application was incorporated by 
reference. The inserted text can be found in the co-pending application beginning at page 15, 
line 4 and continuing through page 1 8, line 2. A few changes were made to the text in order to 
accommodate the different reference ntmibers between the two applications. 
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The additional changes to the specification only seek to correct typographical errors in 
the application. 

The claims have been amended to more particularly claim what applicants regard as the 
subject matter of the present application. 

Separate documents entitled "AMENDMENTS TO SPECIFICATION ON January 5, 
2001" and "PENDING CLAIMS AS OF January 5, 2001" setting forth the precise changes to the 
specification and the claims as they would be pending if the amendment is entered are enclosed 
along with this Preliminary Amendment. 



The application is considered in good and proper form for allowance, and the Examiner is 
respectfully requested to pass this application to issue. 

If, in the opinion of the Examiner, a telephone conference would expedite the prosecution 
of the subject application, the Examiner is invited to call the undersigned attomey. 



Conclusion 



Respectfully submitted. 



Vladan M. Vasiljevic, Reg. No-;^177 
One of the Attomeys for Applfcant(s) 
LEYDIG, VOIT & MAYER, LTD. 
Two Prudential Plaza, Suite 4900 
180 North Stetson 
Chicago, Illinois 60601-6780 
(312) 616-5600 (telephone) 
(312)616-5700 (facsimile) 




Date: January 5, 2001 
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PATENT 

Attorney Docket No. 204849 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

In re Application ^^P^^nTP^tN^ 



For: PROVIDING I^MOTE NETWORK 
DRIVER INTERFACE 
SPECIFICATION SERVICES OVER 
WIRELESS RADIO-FREQUENCY 
MEDIUM 



IN THE SPECIFICATION : 

Please replace the paragraph beginning on page 12, line 1 with the following paragraph: 

Network data is passed between the host 164 and the device 162 over the L2CAP channel 
150. This data can be encapsulated in an NDIS packet mechanism, on the model already used by 
the NDIS network stack. The maximum length of packets supported by L2CAP can be the 
maximum MTU of the media minus [plus] the [maximum] RNIDS header size. The device 152 
can fill in the MaxTransferSize value in an NDIS function call to the largest L2CAP message it 
can send. If the host 164 has a smaller L2CAP maximum message size, it can overwrite the 
returned information with its own maximum message size. Either the host 164 or the device 162 
can initiate the setup of both the control and data L2CAP channels. 

Please replace the paragraph beginning on page 12, line 10 with the following paragraph: 

A minimal Service Discovery Protocol (SDP) record which can be used [sued] for a 
Bluetooth Remote NDIS device can be as shown in Table 1 below. As can be seen, the Remote 
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NDIS device uses the standard Service Discovery description. Personal Area Network (PAN) 
services can communicate with each other. It is possible for a Bluetooth device to have multiple 
PAN services. For example, a cellular phone can have a Wireless WAN server that gives 
Bluetooth devices access to the cellular data network. In such a case the ServiceName can be 
"WWAN'\ or an even more descriptive name. Alternatively, the cellular phone can have a PAN 
service that allows internal PAN service to communicate peer-to-peer between devices. In such 
a case, the ServiceName can be set to "PEER". A device should not advertise more than one 
PAN profile with a ServiceName of PEER. 

Please replace the paragraph beginning on page 14, line 14 with the following paragraph: 

Remote NDIS defines the format for the REMOTE_NDIS_PACKET message including 
space to transport NDIS OOB and per packet information fields. The per packet [perpacket] 
information files can be supplied by NDIS when the remote driver specifies it supports the 
functionality. The OOB information can be supported for particular media types. For example, 
for Ethernet peer-to-peer emulation fields are not required. In such a case, 44 bytes of offsets 
and lengths of packet information fields are not required. Thus, for a 1514 byte Ethemet MTU 
L2CAP can have a minimum of 1554 byte MTU and wastes approximately 3% of the Bluetooth 
bandv^dth. This could be an issue for slow links. This can be optimized if DataOffset is 4, 
assuming the rest of the RNDIS_PACKET header is NULL. This can reduce the data overhead 
to 16 bytes or 1%. 

Please replace the paragraph beginning on page 15, line 1 with the following paragraph: 

In operation, the Bluetooth microport can be loaded when a remote Bluetooth device, 
which supports the PAN service^ is in range and can be communicated to. Loading the microport 
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can cause an initialization message to be sent from the microport. When the remote device is a 
cellular phone, for example, it can respond with an initialization complete message. When the 
remote device is another Windows machine, as another example, it can also generate an 
initialization message. The microport can also receive extra messages such as 
REMOTE_NDIS_INITIALIZE_MSG, REMOTE_NDIS_QUERY_MSG, 
REMOTE_NDIS_SET_MSG, REMOTE_NDIS_RESET_MSG, and 
REMOTE_NDIS_KEEPALIVE_MSG. These messages are described in more detail in the 
article entitled "Remote NDIS Over Bluetooth Specification", dated March 20, 2000, and 
attached at Appendix F. 
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abstracting device control commands and data into a device-independent format; 

establishing a connection-independent driver layer, wherein the connection-independent 
driver layer receives the device control commands and data and encapsulates the device control 
commands and data into a connection-independent format; 

establishing an intermediate driver layer, wherein the intermediate driver layer receives 
the device control commands and data encapsulated in the connection-independent format and 
passes the device control commands and data encapsulated in the connection-independent format 
to a connection-specific driver layer; and 

establishing the connection-specific driver layer, wherein the connection-specific driver 
layer receives the device control commands and data encapsulated in the connection-independent 
format, translates the device control commands and data encapsulated in the connection- 
independent format into connection-specific device control commands and data, and transmits 
the connection-specific device control commands and data to the wireless device. 



PENDING CLAIMS AS OF January 5, 2001 



2. 



A method of creating a device driver for a wireless device, the method comprising 



the steps of: 
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3. The method of claim 2, wherein the wireless device can accept a wireless 
communication conforming to the Bluetooth protocol; and the connection-specific device control 
commands and data conform to the Bluetooth protocol. 

4. The method of claim 2, wherein the connection-specific driver layer transmits the 
connection-specific device control commands and data to the wireless device via at least one 
L2CAP channel. 

5. The method of claim 4, wherein the connection-specific driver layer transmits the 
connection-specific device control commands via a first L2CAP channel and transmits the 
connection- specific data via a second L2CAP channel. 

6. The method of claim 2, wherein the connection-specific driver layer translates the 
device control commands and data encapsulated in the connection-independent format into 
connection-specific device control commands and data with reference to a service discovery 
protocol record. 

7. The method of claim 2, wherein the connection-specific driver layer transmits the 
connection-specific device control commands and data by segmenting the connection-specific 
device control commands and data into packets smaller than a maximum transmission unit of a 
wireless protocol used by the wireless device. 

8. A method of communicating with a wireless device, the method comprising the 
steps of: 
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abstracting device control commands and data into a device-independent format; 
encapsulating the device control commands and data in the device-independent format into a 
connection-independent format; translating the device control commands and data encapsulated 
in the connection-independent format into connection-specific device control commands and 
data; and transmitting the connection-specific device control commands and data to the wireless 
device. 

9. The method of claim 8, v^herein the wireless device can accept a wireless 
communication conforming to the Bluetooth protocol; and the connection-specific device control 
commands and data conform to the Bluetooth protocol. 

10. The method of claim 8, wherein the connection-specific device control conmiands 
and data are transmitted to the wireless device via at least one L2CAP channel. 

1 1 . The method of claim 1 0, wherein the connection-specific device control 
commands are transmitted via a first L2CAP channel and the connection-specific data is 
transmitted via a second L2CAP charmel. 

12. The method of claim 8, wherein the translating of the device control commands 
and data encapsulated in the connection-independent format into connection-specific device 
control commands and data references a service discovery protocol record. 

13. The method of claim 8, wherein the connection-specific device control commands 
and data are transmitted by segmenting the connection-specific device control commands and 
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data into packets smaller than a maximum transmission unit of a wireless protocol used by the 
wireless device. 

14. A computer program product for creating a device driver for a wireless device, the 
computer program product comprising: 

a computer-readable medium carrying computer-executable instructions for abstracting 
device control commands and data into a device-independent format; 

establishing a connection-independent driver layer, wherein the connection-independent 
driver layer receives the device control commands and data and encapsulates the device control 
commands and data into a connection-independent format; 

establishing an intermediate driver layer, wherein the intermediate driver layer receives 
the device control commands and data encapsulated in the connection-independent format and 
passes the device control commands and data encapsulated in the connection-independent format 
to a connection-specific driver layer; and 

establishing the connection-specific driver layer, wherein the connection-specific driver 
layer receives the device control commands and data encapsulated in the connection-independent 
format, translates the device control commands and data encapsulated in the connection- 
independent format into connection-specific device control commands and data, and transmits 
the connection-specific device control commands and data to the wireless device. 

15. The computer program product of claim 14, wherein the wireless device can 
accept a wireless communication conforming to the Bluetooth protocol; and the connection- 
specific device control commands and data conform to the Bluetooth protocol. 
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1 6. The computer program product of claim 1 4, wherein the connection-specific 
driver layer transmits the connection-specific device control commands and data to the wireless 
device via at least one L2CAP channel. 

17. The computer program product of claim 16, wherein the connection-specific 
driver layer transmits the connection-specific device control commands via a first L2CAP 
channel and transmits the connection-specific data via a second L2CAP channel. 

1 8. The computer program product of claim 14, wherein the connection-specific 
driver layer translates the device control commands and data encapsulated in the connection- 
independent format into connection-specific device control commands and data with reference to 
a service discovery protocol record. 

19. The computer program product of claim 14, wherein the connection-specific 
driver layer transmits the connection-specific device control commands and data by segmenting 
the connection-specific device control commands and data into packets smaller than a maximum 
transmission unit of a wireless protocol used by the wireless device. 
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